Closes: #242
(sorry for the huge PR - tried to make everything well tested + make interop tests work with mint)

Covered in this PR

Cover all possible use cases for a gRPC (client-server):

• Unary -> Unary
• Unary -> Stream
• Stream -> Unary
• Steam -> Stream

There is also several E2E test cases here, which includes:

• Canceling requests
• Compressing headers
• Large requests
• Timeout scenarios

Suggestion on how to review

We have two main modules that handles the interactions with the server.

Connection Process

This process is spawned every time we attempt to connect to a gRPC server. It does strictly three things:

• Open and store the Mint connection struct.
• Deals with tcp_messages . And that includes
  • Handling window_size frames
  • pass the headers/trailers/data to the response process
• Handling the requests

Because of HTTP2 flow control mechanics I've designed the request handling of all requests to behave as a streamed request, this way it's easier to check for the window size and chunk the request if necessary. Because of that, you might see that I'm treating even unary requests, as streams - but that behavior is transparent to the user of the lib.

I'm also handling connection drops with the following strategy:

• I close/end all pending requests as suggested here
• I'm also sending an message to the parent process to inform that the connection droped. with the following format:

{:elixir_grpc, :connection_down, self_pid}

Response Process

This process is spawned every time a request is made. It's responsible to receive cast calls from the ConnectionProcess and produce the messages to an Elixir.Stream. It dies when the request is finished - so it should be a short lived process.